I have also made a change to support TMC driver components on the same SPI bus as TFT, SD, Touch, etc. NO PROBLEM! It requires this pull though because SPI is really messed up in the Marlin release.

quiret@9096c4b

You need the following fixed TMCStepper source code to compile the latest code:

TMCStepper_dep.zip

I had no idea that TMCStepper was not part of Marlin, so stuff to be fixed there unfortunately... Head-ache.

Please support this pull request to improve the TMCStepper library: teemuatlut/TMCStepper#255

You can find the most up-to-date version of my TMCStepper here: https://github.com/quiret/TMCStepper

Here are some issues that might be improved/fixed/related to my improvements:

• [BUG] STM32 HAL software SPI bug #23064
• [BUG] TMC 2130 does not work in SPI mode #24516
• [BUG] MKS Robin E3D v1.1 + TMC2130 SPI conflicts with SD Card SPI #22755
• MKS robin e3d v1.1+TMC2130 SPI Fail makerbase-mks/MKS-Robin-E3-E3D#136
• [BUG] SD media init fail  #24716
• stm32f407vet6+25q16 +st7796 spi lvgl not work #24369
• [BUG] enabling #define PSU_CONTROL with TMC2130 drivers causes Marlin not to start  #24263
• [BUG] MKS TS35-R V2.0 with MKS Robin E3D V2.0 not working as expected #24867

My review so far just extends to adjusting formatting and peeking at the new code. I could go through various boards and printers and flash Marlin onto them to see if they boot, but I only have a small batch, and that seems like a lot of work without a huge return. i.e., I wouldn't be able to exercise all the features or catch issues that only arise after an hour of printing. So, my thought is, after the release of Marlin 2.1.3 we should merge this for Foist Testing. That's the testing methodology where we unceremoniously foist the changes upon the world, see what happens, and fix issues as they are found. Not very different from how we test most other changes.

My main concern with any very large overhaul that touches many files is that the build size will explode, or various other things that depend on quirks, accurate timing, or side-effects will explode. This PR touches 457 files, which is enormous by any standard. So if it can be split up into more PRs that have fewer changes each, that would help. For example, it would make it easier to revert related changes without touching others. If we merge this whole PR in one go, we may have a harder time seeing the effects of any one set of changes.

In general, we aim to keep Marlin lightweight and do as little as possible, so there is not a lot of argument validation and other checks, except where we are validating things like G-code input. That is more a concern for AVR than other targets, and also more a concern related to profiling. i.e., If certain code is not being called too often then the tiny bit of extra overhead is not a big deal. Where performance might be impacted, we can always use assert which only gets included in a debug build.

My review so far just extends to adjusting formatting and peeking at the new code. I could go through various boards and printers and flash Marlin onto them to see if they boot, but I only have a small batch, and that seems like a lot of work without a huge return. i.e., I wouldn't be able to exercise all the features or catch issues that only arise after an hour of printing. So, my thought is, after the release of Marlin 2.1.3 we should merge this for Foist Testing. That's the testing methodology where we unceremoniously foist the changes upon the world, see what happens, and fix issues as they are found. Not very different from how we test most other changes.

My main concern with any very large overhaul that touches many files is that the build size will explode, or various other things that depend on quirks, accurate timing, or side-effects will explode. This PR touches 457 files, which is enormous by any standard. So if it can be split up into more PRs that have fewer changes each, that would help. For example, it would make it easier to revert related changes without touching others. If we merge this whole PR in one go, we may have a harder time seeing the effects of any one set of changes.

In general, we aim to keep Marlin lightweight and do as little as possible, so there is not a lot of argument validation and other checks, except where we are validating things like G-code input. That is more a concern for AVR than other targets, and also more a concern related to profiling. i.e., If certain code is not being called too often then the tiny bit of extra overhead is not a big deal. Where performance might be impacted, we can always use assert which only gets included in a debug build.

@thinkyhead The improvements I have attempted to bring are in line with your vision. Any noise, like the unexpected compiler code-gen that increased firmware size for the AVR internals, can be avoided by adjusting the build configurations. And the increase in execution time should not be too big of a deal, especially because of the configurability using preprocessor macros.

I am very sorry that I have to stop my activities on this PR. Marlin firmware will always be dear in my heart and the fork I have made should be an example of my passion for this project. Maybe we can meet again in the future when certain dust has settled and then Marlin can be made greater than before, again with my contributions. I wish the community a great future especially with the recent events regarding online AI scavenging the whole internet. Hold strong and thoughen up! ;)

when certain dust has settled

If you're referring to my personal focus in recent weeks on fixing up the Stepper class / Input Shaping and making preparations for the 2.1.3 release, those dusty tasks should be settled pretty soon, hopefully clearing the way for more comprehensive refactors.

I can make no promises, as my first priority each day is to review and fix up the latest PRs, and then try to attack the backlog, and some weeks are more loaded with new PRs than others. Naturally, the larger and more complex a PR is, the more time it requires for review, and the more that I want to get it tested before merging. If it's a toss-up between spending a whole day on one large PR or trying to get through a bunch, I tend to go through a set of easier ones first.

Of course, I also have aspirations to bring the Documentation site up to date, continue to improve the Auto Build Marlin extension, and spend some time reviewing extant bug reports, but there just aren't enough hours in the day. That said, every PR will get its time in the sun. Refactors have had to take a back-seat to certain features demanded by the community, such as Input Shaping, time-based motion planning, support for the latest boards, fixing motion-related anomalies, etc. Some of my own PRs have been sitting unfinished for months and years, so I must beg the patience of all contributors. As the weather has been improving, so has my mood, and with it my productivity. (We'll see how things go over the coming weeks, as I need spend some of that precious time to find a new apartment.)

One thing that can help get PRs closer to being merged is to get them tested. That is one of the aims of the @ testers role and "testing" channel on Discord, to help contributors find and recruit testers. Testers with the appropriate hardware can certify, at least, that a PR is working and they can provide feedback on their experiences, help locate hidden bugs, and bring more confidence that a PR is safe to merge. Of course, this is an all-volunteer project that everyone works on for fun in their spare time, and it may not always be easy to find help, so I must always beg the patience of contributors.